Columbia Kermit/kermit.zip/newsgroups/misc.19950528-19950726/[e-mail]_Mon Jun 26 12:46:12 1995.msg

Internet Message Format | 2020-01-01 | 5KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA00898
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Mon, 26 Jun 1995 08:46:15 -0400
Received: by apakabar.cc.columbia.edu id AA29550
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 26 Jun 1995 08:46:14 -0400
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: [e-mail] (Frank da Cruz)
Newsgroups: comp.dcom.modems,comp.protocols.kermit.misc
Subject: Re: Improved modem dialing for C-Kermit
Date: 26 Jun 1995 12:46:12 GMT
Organization: Columbia University
Lines: 75
Message-Id: <3sma6k$[e-mail]>
References: <3seuml$[e-mail]> <3sft9o$[e-mail]> <3shhv6$[e-mail]> <3sl921$[e-mail]>
Nntp-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.dcom.modems:99424 comp.protocols.kermit.misc:3043
Apparently-To: [e-mail]

In article <3sl921$[e-mail]>, Leslie Mikesell <[e-mail]> wrote:
>In article <3shhv6$[e-mail]>,
>Frank da Cruz <[e-mail]> wrote:
>In my opinion you would be better off dropping hard-coded dialing
>support completely.
>
I'd like to do that too, but when you begin to support non-Hayes
compatibles, that you lose the ability to be totally table driven.  It's
not only the commands that are different, it's also the very procedures
themselves.  Nevertheless, C-Kermit's new features make it more
table-driven, not less.

>>But that's not the only reason.  The other reason is at the heart of
>>the "Kermit philosophy" (if I may be so pompous).  Our goal is to
>>provide a suite of communication software programs that work consistently
>>across hundreds and hundreds of platforms.  I know that we have not
>>totally succeeded in achieving the goal, but we are working towards it,
>>and we are definitely opposed to working against it.
>
>I disagree with this philisophy when it applies to the user interface
>level since it will almost certainly confuse users when they
>encounter differences from their normal programs.
>
Granted, but (again) we are not talking about Microsoft or Lotus here,
with giant warehouses full of eager-faced programmers to crank out the
user interface ju jour, on a "jourly" basis, as corporations and amorphous
consortia thereof invent new three-letter acronyms with which we all must
comply or perish -- no, we have to stretch the work of a very small group
of people to cover a very large number of platforms and a huge number of
users.  (And if we were talking about Microsoft or Lotus, we would not be
having this conversation :-)

>How do I make kermit automatically select a suitable free modem from
>those available on the machine? (Preferably without having to keep
>a user base aware of changes or modify scripts every time a modem
>is replaced or moved).
>
That would be highly dependent not only on the underlying platform,
but also on its specific configuration, and therefore is best done with
a Kermit script program, as you go on to suggest...

>How do I add the ability to connect over a new modem or device type
>that you didn't anticipate (for example an X.25 PAD or a satellite
>link that uses similar commands)?
>
Hopefully you will be able to use C-Kermit's new "set modem type
user-defined" feature for this.  That's what it's for.  I'd appreciate
specific constructive feedback on how / whether it can be used to handle
oddball situations, and detailed examples thereof.

>The Devices and Dialers files in HDB uucp provide a general solution
>to these questions.  Rather than re-invent that solution or provide
>less general hard-coded knowledge of specific devices that most people
>don't have imbedded in every binary, why not duplicate it with some
>macros in kermit and simply create the files for systems where they
>don't already exist?  You do need some concepts that didn't exist
>in pre-HDB versions, like modem 'classes' rather than speeds in the
>Devices file to get it right, though.
>
But aren't we moving away from the timesharing world, where a bunch of
users on the same machine are competing for the same pool of dialout
ports.  An increasing proportion of C-Kermit users has total control of
the computer they are using.  And when dialout ports are pooled, they are
more likely to be on some kind of communication server that already
handles this problem without the communications software needing to know a
thing about it, e.g. reverse terminal servers where telnet'ing to port
2000 gives you the first free dialout port.

But still, a scripted approach to finding a free dialout port and picking
up its essential characteristics, is obviously a good idea in environments
where it is needed.  Would anybody like to take a shot at it?  There is an
example of this kind of thing in kermit/f/ckeracu.ini on kermit.columbia.edu,
very close to what you are talking about.

- Frank